Cap. 5 Testarea sistemelor informatice 


Dezvoltarea rapidă a tehnologiilor informaţionale a determinat 
extinderea rapidă a ariei de informatizare, condiţii în care calitatea 
existenţei noastre depinde din ce în ce mai mult de calitatea sistemelor 
informatice cu care lucrăm. Din acest motiv, trebuie acordată o atenţie 
deosebită calităţii sistemelor informatice ceea ce solicită acordarea 
importanţei cuvenite activităţilor de testare. 

Apariţia erorilor pe parcursul întregului proces de dezvoltare a 
sistemului informatic este inerentă, multe erori sunt descoperite după 
mulţi ani de exploatare a sistemului, iar altele nu sunt descoperite 
niciodată. Explicaţiile pot fi numeroase, însă dintre acestea mai 
importante sunt: 

> Chiar dacă s-au înregistrat reale progrese, metodele, tehnicile 
şi instrumentele de dezvoltare a sistemelor informatice sunt 
încă departe de a fi perfecte. Metodele şi tehnicile de analiză 
şi proiectare au un caracter mai puţin fundamentat teoretic, 
iar aplicarea lor este mai puţin riguroasă. 

> Inabilitatea oamenilor de a-şi realiza sarcinile de lucru şi de a 
comunica în mod perfect. Erorile pot să apară în toate fazele 
procesului de dezvoltare a sistemului informatic, ele fiind 
determinate adesea de: definirea neclară şi incorectă a 
obiectivelor sistemului; identificarea incompletă, formularea 
şi structurarea greşită a cerinţelor informaţionale şi 
funcţionale; alegerea unor soluţii de proiectare 
necorespunzătoare; întocmirea incorectă a specificaţiilor de 
proiectare; transpunerea necorespunzătoare a specificaţiilor 
de proiectare în programele sursă; greşeli de programare etc. 

> Testarea este la fel de dificilă precum proiectarea. Testarea 
exhaustivă a programelor este practic imposibilă, rolul ei fiind 
acela de a semnala prezenţa erorilor şi nu absenţa acestora. 

> Atenţia relativ redusă acordată activităţilor de testare. 
Adesea, sub presiunea timpului şi a lipsei resurselor 
financiare (lucru explicabil cumva, dacă ne gândim că 
majoritatea activităţilor de testare se desfăşoară în ultima 
parte a procesului dezvoltării sistemului informatic), se 
ajunge la ignorarea, amânarea sau realizarea superficială a 
testării sistemului. 

În general, cheltuielile asociate activităţii de testare deţin o 
pondere de 30-40% din totalul cheltuielilor necesare dezvoltării unui 
sistem informatic dintr-o organizaţie. În domeniile cu activităţi critice 
(controlul traficului aerian, monitorizarea reactoarelor nucleare etc.) 
aceste cheltuieli pot fi de 3-5 ori mai mari decât toate celelalte cheltuieli 
cu dezvoltarea sistemului informatic!. 


5.1 Fundamentele testării sistemelor informatice 


Testarea reprezintă o activitate critică privind calitatea sistemelor, 
ea reprezentând o ultimă ocazie pentru revizuirea cerinţelor sistemului, a 
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specificaţiilor de proiectare şi a programelor sursă. Obiectivul general al 
fazei de testare îl reprezintă identificarea numărului maxim de erori 
cu efort minim. 

Testarea este un termen mai general care face referire la alte două 
noţiuni: verificarea şi validarea. Verificarea reprezintă procesul de 
evaluare a sistemului sau a unei componente a sistemului pentru a se 
determina dacă o anumită funcţie a fost implementată corect, oferind 
răspunsul la întrebarea: Sistemul a fost construit bine? Validarea poate fi 
definită ca procesul de evaluare a sistemului sau a unei componente a 
sistemului pentru a se determina dacă sunt respectate cerinţele 
funcţionale identificate în faza de analiză, răspunzând la întrebarea: A 
fost construit sistemul care trebuie? Aşadar, verificarea vizează modul 
cum a fost construit sistemul, iar validarea se referă la ce a fost 
construit. Atât verificarea cât şi validarea trebuie desfăşurate pe 
parcursul întregului proces de dezvoltare a sistemului, nu doar la 
sfârşitul acestuia. 

Testarea întregului sistem nu este practic posibilă, deoarece ea nu 
ar fi fezabilă economic şi tehnic. Un exemplu simplu este edificator: dacă 
un program conţine două structuri de control repetitive imbricate, fiecare 
din cele două structuri presupunând un număr de iterații cuprins între 1 
şi 20, iar structura de control interioară conţine patru structuri de control 
alternative simple, atunci numărul ramurilor logice din program care 
trebuie testate va fi de 1011! 

Desfăşurarea procesului de testare are loc în maniera schiţată în 
figura 5.1. P reprezintă obiectul supus testării, respectiv un modul de 
program, specificaţiile procedurale, sistemul etc. Una din cele mai dificile 
activităţi din faza de testare o reprezintă generarea unui subset din 
domeniul intrărilor care să reprezinte setul de teste ce vor fi realizate. In 
acest scop, este necesară definirea unei strategii pe baza căreia să se 
definească setul minim de teste care să satisfacă cerinţele testării, 
cuantificate prin intermediul criteriilor de acceptabilitate. De exemplu, 
criteriile de acceptabilitate pot fi exprimate astfel: la testare se va urmări 
execuţia cel puţin odată a tuturor instrucţiunilor din program; prin 
testare se va urmări execuţia tuturor ramurilor logice din program etc. 
Evident că cele două exemple nu sunt echivalente, întru-cât primul 
criteriu nu permite testarea ramurilor vide. 
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Figura 5.1 Schema generală a procesului de testare 
(adaptare după van Vliet, H., Software Engineering. Principles and Practicies, John 
Wiley & Sons, 2000, p. 401) 


După stabilirea criteriilor de acceptabilitate se va trece la 
generarea setului de teste care să răspundă acestor criterii. Această 
activitate nu se desfăşoară la întâmplare, ci de-o manieră sistematică, 
apelând la diferitele tehnici de testare pe care le avem la dispoziţie. De 
fapt, strategia de testare presupune, în principal, alegerea tehnicilor de 
testare şi organizarea lor în vederea satisfacerii criteriilor de 
acceptabilitate definite. Asupra strategiei de testare şi a tehnicilor de 
testare vom reveni cu detalii în paragrafele următoare. 

După definirea setului de teste, pentru fiecare test în parte vor fi 
determinate rezultatele aşteptate şi se va executa programul sau modulul 
ce trebuie testat. Rezultatele obţinute în urma execuţiei vor fi comparate 
cu cele aşteptate, eventualele diferenţe semnalând existenţa unor erori, 
ce vor fi transmise spre rezolvare proiectanţilor sau programatorilor 
responsabili de componenta testată. 

Rezultatele testării, dar şi celelalte aspecte ale procesului de 
testare vor fi consemnate într-o documentaţie specială a sistemului. 

Există câteva principii generale care ghidează activitatea de testare 
a programelor: 

Testele trebuie concepute astfel încât să urmărească respectarea 
cerințelor utilizatorilor. Cele mai numeroase erori sunt legate de 
nesatisfacerea cerinţelor sistemului, identificate şi formulate în 
faza de analiză. 

2. Testele trebuie planificate cu mult timp înainte de începerea 
activităţii de testare. Toate testele trebuie planificate şi 
proiectate înainte de scrierea/generarea programelor sursă, 
chiar din timpul analizei sistemului odată ce modelul cerinţelor 
sistemului este complet. Definirea detaliată a cazurilor de testat 
poate începe încă din timpul fazei de proiectare, odată cu 
întocmirea specificaţiilor de proiectare. 

3. Testarea trebuie să înceapă cu detaliile, desfăşurată la nivelul 
modulelor componente, iar pe măsură ce testarea progresează 
atenţia va fi îndreptată spre identificarea erorilor de integrare a 
acestor componente şi, în final, asupra întregului sistem. 

4. Testarea exhaustivă nu este posibilă. Numărul cazurilor de 
testat, derivate din combinarea tuturor situaţiilor posibile, este 
foarte mare chiar şi pentru programele de dimensiuni mai mici. 
De aceea, este necesară utilizarea unor tehnici speciale de 
definire a cazurilor de test care să corespundă criteriilor de 
acceptabilitate. 

5. Pentru a fi eficientă, testarea trebuie să fie realizată de persoane 
care nu au fost implicate în fazele anterioare de dezvoltare a 
sistemului. Chiar dacă nu trebuie interpretat în mod absolut 
acest principiu totuşi, de cele mai multe ori, persoanele 
implicate în crearea sistemului nu sunt cele mai indicate în 
realizarea testării programelor, cu excepţia aplicaţiilor de 
dimensiuni mai mici. 

6. Testarea nu vizează numai produsul final, ci şi rezultatele fazelor 
intermediare ale dezvoltării sistemului informatic. Nu doar 
programele sunt supuse testării, ci şi cerinţele informaţionale şi 
funcţionale ale sistemului (structurate în faza de analiză), 
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soluţiile generale de proiectare, specificaţiile detaliate de 
proiectare (întocmite în fazele proiectării logice şi fizice), 
documentaţia sistemului etc. Cele mai grave erori sunt cele 
derivate din incompleta identificare sau formularea greşită a 
cerinţelor sistemului. 


5.2 Tehnici de testare 


5.2.1 Clasificarea tehnicilor de testare 

Tehnicile de testare au un caracter preponderent euristic şi 
empiric, mai puţin fundamentate teoretic, ceea ce explică multitudinea 
tehnicilor prezentate în literatura de specialitate. Importantă este 
alegerea unei strategii prin care să se selecteze tehnicile cele mai 
adecvate pentru atingerea obiectivelor definite în faza de planificare a 
testării. Pentru a fi în măsură de a alege cele mai potrivite tehnici de 
testare este necesară cunoaşterea modalităţilor de clasificare a lor. 

Un prim criteriu de clasificare îl reprezintă modul de efectuare a 
testării, conform căruia există două categorii de tehnici: 

> tehnici de testare automată, care presupun testarea 
programelor sub controlul calculatorului şi 

> tehnici de testare manuală, prin care testarea este 
efectuată sub controlul omului. 

Un criteriu de clasificare asemănător se referă la execuţia sau nu a 
programelor pe parcursul testării. În funcţie de acest criteriu, tehnicile 
de testare se împart tot în două categorii: 

> testarea statică, presupune verificarea programelor sursă 
fără ca acestea să fie lansate în execuţie. Multe din aceste 
tehnici sunt aplicate la testarea rezultatelor fazelor de analiză 
şi proiectare sau a documentaţiei sistemului; 

> testarea dinamică implică execuţia programelor. Pornind de 
la un set de date de intrare se va lansa în execuţie programul 
şi se vor compara rezultatele execuţiei programului cu 
rezultatele scontate. 

Cele două moduri de clasificare sunt relativ redundante, în sensul 
că majoritatea tehnicilor de testare manuală se regăsesc şi în categoria 
tehnicilor de testare statică, atât timp cât, în general, tehnicile manuale 
nu implică execuţia programelor?, iar tehnicile de testare automată 
presupun de cele mai multe ori execuţia programelor, deci ele sunt 
considerate tehnici de testare dinamică. 

In funcţie de sursele de informaţii utilizate pentru generarea 
cazurilor de test, un sistem informatic poate fi testat în două moduri 
complementare: 

e Testarea tip „cutia neagră”, prin care se urmăreşte să se 
verifice dacă fiecare funcţie a programului este operaţională, 
precum şi să se identifice eventualele erori în realizarea unei 
funcţii. Acest tip de testare include testele efectuate asupra 
interfeţelor programului, vizând intrările (dacă datele 
acceptate spre prelucrare sunt corecte), ieşirile (dacă ieşirile 
obţinute prin prelucrarea datelor de intrare sunt corecte) şi 
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baza de date (dacă este asigurată consistenţa bazei de date). 
Cu alte cuvinte, prin acest tip de testare sunt examinate 
aspectele fundamentale ale programului, acordându-se o 
atenţie mai mică logicii interne a programului. 

e Testarea de tip „cutia albă”, spre deosebire de tipul 
anterior de testare, presupune concentrarea atenţiei asupra 
logicii interne a programelor, respectiv asupra detaliilor 
procedurale. Ea presupune identificarea cazurilor de test care 
permit execuţia tuturor ramurilor programului, derivate din 
structurile de control alternative şi/sau repetitive. Prin 
urmare, acest tip de testare presupune identificarea tuturor 
ramurilor logice ale programului, definirea cazurilor de test, 
execuţia lor şi evaluarea rezultatelor. 

După cum a fost definită anterior, testarea de tip „cutia albă” 
presupune analiza structurilor de control din specificaţiile procedurale de 
proiectare în vederea definirii cazurilor de test. S-ar putea crea impresia 
că aplicarea acestui tip de testare ar conduce inevitabil către obţinerea 
de programe 100% corecte şi că testarea de tip „cutia neagră” ar fi total 
inutilă. Ar putea fi adevărat dacă ar fi posibilă testarea exhaustivă a 
programelor (reamintiţi-vă unul din principiile testării enunțate anterior). 

Problema poate fi formulată şi din cealaltă perspectivă: de ce 
trebuie să cheltuim atâta timp şi energie cu testarea la nivelul detaliilor 
programelor, în loc să ne concentrăm atenţia asupra testelor care să 
arate dacă programele corespund cerinţelor formulate? Altfel formulată 
întrebarea, de ce să ne complicăm cu testarea de tip „cutia albă” în loc să 
ne consumăm toate resursele cu testarea de tip „cutia neagră”? 

Răspunsurile sunt numeroase şi derivă din natura erorilor întâlnite 
în programe. Multe erori apar atunci când se proiectează şi 
implementează funcţii, condiţii sau structuri de control care privesc 
cazurile speciale ale problemei tratate şi care nu fac parte din fluxul logic 
principal al programului. În acest sens, se estimează că numărul erorilor 
logice este invers proporţional cu probabilitatea de execuţie a unei 
ramuri logice a programului”. Erorile de scriere a programelor sursă pot 
apare oriunde în programe, atât în ramurile logice principale cât şi în cele 
care tratează cazurile speciale. Chiar dacă unele din erorile de scriere a 
programelor sunt depistate cu ocazia compilării programelor sursă, multe 
din aceste erori rămân nedescoperite, ceea ce justifică necesitatea 
tehnicilor de testare de tip „cutia albă”. 

Pe de altă parte, aplicarea tehnicilor de testare de tip „cutia albă” 
permite identificarea şi localizarea mai uşoară a erorilor, tocmai datorită 
faptului că acest tip de testare se desfăşoară la nivelul detaliilor 
procedurale. Să ne imaginăm ce dificilă ar fi localizarea unei erori 
identificate la testarea unei funcţii a sistemului ce presupune execuţia 
mai multor module de program. În plus, noi ştim că rezultatele obţinute 
nu sunt corecte, dar ar putea fi vorba de mai multe erori şi nu doar una 
singură. Acesta este unul din motivele pentru care, de regulă, strategia 
de testare a programelor presupune aplicarea mai întâi a tehnicilor de 
testare de tip „cutia albă” şi apoi a celor de tip „cutia neagră”. 
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Tehnicile de testare de tip „cutia albă” urmăresc generarea 
cazurilor de test astfel încât: 

e Să se garanteze că toate ramurile independente dintr-un 
modul vor fi executate cel puţin o dată; 

e Execuţia fiecărei structuri de control alternative pe ambele 
ramuri; 

e Execuţia fiecărei structuri de control repetitive atât la 
numărul minim cât şi maxim al iteraţiilor, dar şi un număr 
intermediar. 

e Verificarea validității structurilor de date interne ale 
programelor. 

Testarea de tip „cutia neagră”, prin testele proiectate, urmăreşte să 
ofere răspunsuri la următoarele întrebări: Cum poate fi testată validitatea 
funcţională a aplicaţiei? Cum pot fi testate performanţele aplicaţiei? Ce 
clase de intrări sunt necesare pentru o bună testare a sistemului? Ce 
volum de date şi ce rata a intrărilor poate accepta sistemul? Ce efect va 
avea asupra modului de funcţionare a sistemului o anumită combinaţie a 
datelor de intrare? 

În realizarea acestui tip de testare, un rol important îl au 
diagramele fluxurilor de date, pe baza cărora se pot defini clasele de 
intrări care să permită testarea eficace a fiecărei tranzacţii şi a fiecărui 
pas în realizarea unei tranzacţii (dacă sistemul informaţional este orientat 
pe tranzacţii) sau a fiecărei transformări efectuate asupra datelor (dacă 
sistemul informaţional este orientat pe transformări). În acest sens, 
pornind de la diagramele fluxurilor de date, se poate realiza testarea pe 
baza unor grafuri, în care nodurile reprezintă paşii (operaţiunile) 
necesare în efectuarea unei tranzacţii, iar legăturile reprezintă 
conexiunile logice dintre paşi. În cazul sistemelor orientate pe 
transformări, nodurile reprezintă datele, iar legăturile dintre noduri 
reprezintă transformările. 

Vliet face o prezentare a tehnicilor de testare clasificându-le în 
funcţie de obiectivele urmărite la generarea cazurilor de test. Astfel, el le 
grupează în trei categorii“: 

> Testarea bazată pe gradul de acoperire, în care cerinţele 
testării sunt specificate prin gradul de acoperire a produsului 
ce trebuie testat. Prin noţiunea de produs se face referire la 
programe, documente ce conţin specificaţii de proiectare sau 
cerinţele funcţionale structurate în faza de analiză. De 
exemplu, se poate solicita: generarea cazurilor de test astfel 
încât prin execuţia lor să se garanteze că toate instrucţiunile 
din program sau un anumit procent din instrucţiuni vor fi 
executate cel puţin odată; toate cerinţele elementare ale 
sistemului, formulate în faza de analiză, să fie exersate cel 
puţin odată. 

> Testarea axată pe greşeli include tehnicile orientate spre 
detectarea greşelilor. Spre deosebire de categoria anterioară, 
când se pornea de la premisa că o arie cât mai mare de 
acoperire a produsului de testat este cea mai bună strategie 
de testare, tehnicile de testare din această categorie 
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urmăresc să identifice setul de teste cu cea mai mare 
capacitate de detectare a greşelilor. Prin urmare, nu mai sunt 
avute în vedere produsele de testat ci chiar seturile de teste 
ce vor fi utilizate la testarea produselor respective. De 
exemplu, se pot introduce în mod intenţionat un număr de 
greşeli într-un program, după care se va verifica dacă un 
anumit set de teste va detecta un procent minim din greşelile 
introduse; dacă nu, atunci se renunţă la setul de date de 
intrare respectiv. În concluzie, trebuie reţinut că aceste tipuri 
de tehnici nu sunt utilizate la generarea seturilor de teste ci 
la validarea şi alegerea celor mai potrivite seturi de teste 
scopurilor propuse. 

> Testarea axată pe erori este orientată spre depistarea 
erorilor, pornindu-se de la erorile tipice întâlnite la 
proiectarea şi scrierea programelor. 

Din perspectiva planificării şi desfăşurării activităţii de testare, o 
importanţă deosebită o prezintă clasificarea tehnicilor de testare în 
funcţie de momentul sau etapa în care ele sunt invocate. Astfel, ele pot fi 
grupate în: 

Testarea modulelor, 

Testarea integrării modulelor, 

Testarea sistemului şi 

Testarea de acceptare din partea utilizatorilor. 

În final, trebuie reţinut că nu există o tehnică de testare sau o 
categorie de tehnici care să fie catalogată drept cea mai bună. Fiecare 
tehnică este orientată spre detectarea anumitor tipuri de erori sau 
satisfacerii anumitor obiective. Din acest motiv, descoperirea cât mai 
multor erori necesită utilizarea mai multor tehnici, în funcţie de 
obiectivele propuse pentru faza de testare, strategia de testare, 
complexitatea sistemului informatic, resursele alocate testării etc. 
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5.2.2 Tehnica testării căilor de bază 
Testarea dinamică implică urmarea unei căi prin fluxul logic de 

control al programului, în funcţie de parametrii şi datele de intrare, 
structurile de control existente şi expresiile logice conţinute în structurile 
de control. Tehnica căilor de bază a fost propusă pentru prima dată în 
1976 de Tom McCabe şi presupune determinarea indicatorului 
complexitatea logică a specificaţiilor procedurale, pe baza căruia se va 
defini un set de bază al căilor independente de execuţie a programului. Pe 
baza căilor independente de execuţie definite, se vor putea genera 
cazurile de test care să garanteze execuţia cel puţin o dată a fiecărei 
instrucţiuni din program. 

PROCEDURE EvaluareFIFO 

* Acest modul realizeaza evaluarea stocurilor la iesire dupa metoda „First In - 
First Out” 

INTERFACE INPUT cMatCod, vCantitate 

INTERFACE OUTPUT aConsum, bConsValid 

vCantConsum = 0 

SELECT Datalntrare,Stoc,Pret; 

FROM Stoc ; 

INTO ARRAY aStocuri ; 

(D< WHERE MatCod = cMatCod and Stoc > 0; 


ORDER BY Datalntrare 
n = ALEN(aStocuri, ROW’) 


DIMENSION aConsum(n, 

i=1 p 

DO WHILE îi «3 AND vCantConsum < v()titate 

(4) IF vCantitate - vCantConsum >= aStocuri(i,2) 
INCREMENT vCantConsum BY aStocuri(i,2) 
© aConsum(i,1) = aStocuri(i,1) 
aConsum(i,2) = aStocuri(i,2) 
aConsum(i,3) = aStocuri(i,3) 
ELSE 
aConsum(i,1) = aStocuri(i,1) 

(6) aConsum(i,2) = vCantitate - vCantConsum 
aConsum(i,3) = aStocuri(i,3) 
vCantConsum = vCantitate 

2 END IF 

INCREMENT i BY 1 
END DO 
IF vCantConsum < vCan(9)te 


bConsValid = FALS 
9 DISPLAY MESSAGE(,„Stocul este insuficient”) 
E 


SE 
bConsValid = TRUE 
ENDIF 
END 
Figura 5.2 Exemplu de identificare a nodurilor grafului fluxurilor logice 
de control 


Tehnica testării căilor de bază presupune parcurgerea următorilor 
paşi: 

1. Construirea grafului fluxurilor logice de control din program, 
pe baza pseudocodului sau a programului sursă. 

Printr-un astfel de graf se pun în evidenţă fluxurile logice de control 
dintr-un program. Construirea grafului nu este obligatorie, însă el 
permite o mai bună înţelegere a logicii programelor, mai ales în cazul 
modulelor complexe. 

Construirea grafului poate fi realizată apelându-se la notaţiile din 
figura 5.3. Fiecare nod al grafului, reprezentat printr-un cerculeţ, 
reprezintă una sau mai multe instrucţiuni program, iar săgețile dintre 
noduri reprezintă fluxurile logice interne de control din cadrul unui 
program sau modul de program. Orice săgeată trebuie aibă la capătul său 
un nod, chiar dacă este posibil ca acelui nod să nu-i corespundă nici o 
instrucţiune. 


Secven If- then - Do Do- 


[> i 
. > > 


Figura 5.3 Construcţiile elementare pentru crearea grafului fluxurilor 
logice de control 


Printr-un nod se poate reprezenta un grup de instrucțiuni 
secvențiale şi o instrucțiune care codifică o structură de control. In cazul 
în care structura de control conține o condiție compusă, se va crea câte 
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un nod separat pentru fiecare condiţie elementară. O condiţie compusă 
reprezintă o expresie logică care conţine unul sau mai mulţi operatori 
logici (OR, AND). Fiecare nod care conţine o condiţie se numeşte nod 
predicativ şi are drept caracteristică faptul că din acel nod vor pleca cel 
puţin două săgeți. Pentru pseudo-codul din figura 5.2, graful fluxurilor 
logice de control este prezentat în figura 5.4. 


? 


JON 
A a 


(8) 


Figura 5.4 Graful fluxurilor logice de control pentru procedura 
EvaluareFIFO 


2. Determinarea complexităţii ciclomatice pe baza grafului obținut 
anterior. 

Complexitatea ciclomatică este un indicator prin intermediul căruia 
se măsoară complexitatea logică a unui program. El defineşte numărul 
căilor de execuţie independente, dar şi numărul maxim de teste care 
trebuie realizate astfel încât să fie garantată execuţia cel puţin o dată a 
fiecărei instrucţiuni din program. 

O cale independentă de execuţie a programului reprezintă orice 
cale prin program care implică cel puţin un nou grup de instrucţiuni sau o 
condiţie nouă faţă de cele definite anterior. 

Complexitatea ciclomatică poate fi determinată în mai multe 
moduri. Unul din acestea: 

CC=P +1, 

în care P reprezintă numărul nodurilor predicative din graful 
fluxurilor de control. 

În exemplul luat, avem patru noduri predicative, respectiv nodurile 
2, 3, 4 şi 9. În graful din figura 5.4 se observă că pentru fiecare din cele 
patru noduri predicative există cel puţin două fluxuri care pleacă din acel 
nod. Aplicând formula prezentată anterior, rezultă că pentru modulul din 
exemplul nostru, complexitatea ciclomatică este 5 (4 + 1). 

3. Determinarea setului de bază al căilor liniare independente de 

execuție. i 

Noţiunea de cale independentă a fost prezentată anterior. Într-un 
graf al fluxurilor de control, o cale independentă trebuie să conţină cel 
puţin un flux de control (adică un arc) ce nu a fost inclus într-o altă cale 
definită anterior. 

În exemplul nostru, cele cinci căi independente sunt: 


Calea 1: 1-2-9-10-12 

Calea 2: 1-2-9-11-12 

Calea 3: 1-2-3-9-10-12 
Calea 4: 1-2-3-4-5-7-8-2-..... 
Calea 5: 1-2-3-4-6-7-8-2.-..... 


4. Pregătirea cazurilor de test care vor permite execuţia fiecărei 
căi liniare din setul de bază definit anterior. Pregătirea fiecărui caz de 
test implică definirea datelor de test corespunzătoare condiţiilor 
specificate în nodurile predicative şi a rezultatelor aşteptate. Urmează 
execuţia fiecărui caz de test şi compararea rezultatelor obţinute cu cele 
aşteptate. 

În modulul EvaluareFIFO observăm că în afara celor doi parametri, 
codul materialului (cMatCod) şi cantitatea consumului (vCantitate), mai 
există o intrare, respectiv accesarea pentru citire a tabelei Stocuri 
realizată prin fraza SELECT. Prin urmare, la definirea datelor de test 
pentru fiecare din cele cinci cazuri de test trebuie să avem în vedere şi 
starea bazei de date în momentul accesării ei. 

De exemplu, pentru calea 4 putem alege următoarele date de test: 
în tabela stocuri vor exista trei linii pentru materialul cu codul “100001”, 
iar valorile pentru atributul Stoc vor fi 50, 65 şi 40 (valorile pentru 
celelalte câmpuri ale tabelei nu sunt relevante pentru cazul nostru de 
test); valoarea parametrilor transmişi de modulul apelant vor fi “100001” 
pentru codul materialului şi 100 pentru cantitatea de consum. 
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5.2.3 Testarea structurilor de control repetitive. 

Structurile repetitive stau la baza majorităţii algoritmilor 
implementaţi în programe. Ele pot fi împărţite în trei categorii: simple, 
imbricate şi concatenate, prezentate în figura 5.5. 

In cazul structurilor repetitive simple, considerând n - numărul 
maxim de iterații, trebuie realizate următoarele teste: nici o iteraţie 
(adică nici o trecere prin bucla respectivă), o singură trecere, două 
treceri, m treceri (unde m<n), n-1, n, n+1 treceri. 

Pentru structurile de control repetitive imbricate, numărul testelor 
posibile creşte în progresie geometrică cu nivelul de imbricare. 
Reducerea numărului de teste se poate realiza astfel: 

1. Se porneşte cu structura repetitivă de pe nivelul cel mai mare de 
imbricare (prima din interior), configurându-se celelalte 
structuri la numărul minim de iterații. Pentru această structură 
de control se realizează testele specifice structurii repetitive 
simple, amintite anterior. 

2. Se continuă testele specifice structurii repetitive simple pentru 
testarea structurii de control situate pe nivelul următor de 
imbricare, păstrându-se structurile de control situate deasupra 
sa la numărul minim de iterații şi valorile tipice pentru cele 
situate dedesubt. 

3. Se continuă în aceeaşi manieră până când se testează toate 
structurile de control. 


a 
g 


structu structur structuri 

ri i repetitiv 
iti repetiti e 

A dia si concaten 


bee, , F . i ate 
simgera 5.5 Tipuri de stimeriaa de control repetitive 


Structurile concatenate pot fi testate în maniera descrisă în cazul 
structurilor simple, dacă fiecare din structurile de control concatenate 
este independentă de celelalte, sau structurilor imbricate, dacă 
structurile de control concatenate nu sunt independente. Două structuri 
de control concatenate nu sunt independente atunci când condițiile 
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conţinute de cele două structuri sunt legate între ele, cum ar fi în cazul a 
două structuri de tip FOR, în care contorul primei structuri de control 
este utilizat ca valoare iniţială pentru cea de-a doua structură. 


5.2.4 Testarea pe baza analizei fluxurilor de date 

Această tehnică de testare presupune selectarea căilor de execuţie 
a programelor în funcţie de locurile în care sunt definite sau utilizate 
variabilele de memorie. În acest scop se poate apela la graful fluxurilor 
logice de control utilizat la tehnica căilor de bază. 

Analiza fluxurilor de date dintr-un program ia în considerare 
definirile şi utilizările variabilelor de memorie de-a lungul căilor de 
execuţie ale programului. Prin definirea unei variabile se face referire la 
atribuirea unei valori variabilei respective printr-o instrucţiune program. 
Ulterior, când noua valoare este referită într-o instrucţiune, se vorbeşte 
despre o utilizare a variabilei respective. Combinația „definire - utilizare” 
are acelaşi sens cu „atribuire - referire”. 

La baza analizei fluxurilor de date stă noţiunea lanțul „definire - 
utilizare” al unei variabile. Fie X şi Y două instrucţiuni dintr-un program. 
O definire în instrucţiunea X este valabilă în instrucţiunea Y dacă şi 
numai dacă există o cale între X şi Y care să nu conţină un nod 
intermediar prin care să se atribuie o nouă valoare variabilei respective. 
O astfel de cale reprezintă un lanţ „definire - utilizare” al variabilei 
respective. Pot fi distinse două tipuri de utilizări ale unei variabile: 
utilizări-predicative (utilizări-P), cum ar fi cea în care o variabilă este 
referită în condiţia unei structuri de control alternative, şi utilizări-în- 
calcule (utilizări-C), atunci când variabila respectivă este utilizată în 
calcule sau instrucţiuni de citire/scriere. 

Diferenţiarea celor două tipuri de utilizări este importantă pentru 
definirea criteriilor de acoperire a testării, în funcţie de care pot fi 
definite mai multe strategii de testare a fluxurilor de date din programe. 
Una din cele mai simple strategii presupune testarea fiecărui lanţ 
definire-utilizare pentru fiecare variabilă în parte. Chiar dacă această 
strategie asigură testarea tuturor utilizărilor pentru fiecare definire şi 
variabilă în parte, ea nu garantează testarea tuturor ramurilor 
programului. De exemplu, o structură de control alternativă de tip IF- 
THEN-ELSE în care ramura THEN nu conţine nici o definire a vreunei 
variabile iar ramura ELSE este vidă nu va fi testată. 

Alte criterii pentru definirea strategiei de testare pot fi: 

> Testarea tuturor definirilor solicită ca fiecare definire să fie 
cel puţin odată utilizată la execuţia setului de teste definit; 

> Testarea tuturor utilizărilor-C/câteva utilizări-P 
presupune testarea tuturor lanțurilor „definire-utilizare” 
rezultate prin combinarea fiecărei definiri cu toate utilizările- 
C corespunzătoare. Dacă o definire este implicată doar în 
utilizări-P, se va executa cel puţin un lanţ „definire-utilizare” 
în care definirea variabilei este implicată într-o utilizare-P; 

> Testarea tuturor utilizărilor-P/câteva utilizări-C 
presupune testarea tuturor lanțurilor „definire-utilizare” 
rezultate prin combinarea fiecărei definiri cu toate utilizările- 
P. Dacă o definire este implicată doar în utilizări-C, se va 


12 


executa cel puţin un lanţ „definire-utilizare” în care definirea 
variabilei este implicată într-o utilizare-C; 

> Testarea tuturor utilizărilor-P implică testarea tuturor 
lanțurilor  „definire-utilizare” de la fiecare definire către 
fiecare utilizare-P. 


5.2.5 Examinările şi execuțiile de probă 

Ambele tehnici de testare sunt manuale, iar aplicarea lor presupune 
constituirea unor echipe speciale care vor evalua programele şi 
specificaţiile procedurale în cadrul unor sesiuni formale de lucru, 
urmându-se anumite proceduri clar definite. 

Examinările presupun evaluarea programelor linie cu linie în 
vederea depistării manuale a unor erori des întâlnite, fără a se urmări 
efectul fiecărei instrucţiuni. De aceea, este necesară întocmirea unei liste 
de control cu erorile tipice întâlnite în activităţile de proiectare şi 
programare. Astfel de erori privesc: 

> Utilizarea greşită a datelor: referirea unor variabile 
neiniţializate sau chiar nedeclarate, depăşirea dimensiunii 
unui tablou de date etc; 

> Erori în expresiile de calcul: împărţirea la 0, utilizarea unor 
variabile de tipuri diferite în aceeaşi expresie fără a se apela 
la funcţiile de conversie, nerespectarea ordinii de prioritate a 
operatorilor, plasarea eronată a parantezelor etc; 

> Erori legate de fluxul logic de control: structuri de control 
repetitive infinite, blocuri de instrucţiuni ce nu vor putea fi 
executate etc; 

> Erori în interfeţe: utilizarea unui număr incorect de parametri 
sau a unor parametri al căror tip nu este corespunzător etc. 

În general, o echipă de examinare este formată din patru membri, 
fiecare cu roluri bine definite. Moderatorul este responsabil pentru 
organizarea şedinţelor de lucru, le conduce, asigură ca fiecare participant 
să urmeze procedurile stabilite astfel încât aceştia să lucreze ca o echipă. 
Echipa conţine, de regulă, doi inspectori (examinatori) care vor interpreta 
programul sursă. Din echipă va face parte şi programatorul, respectiv cel 
ce a scris codul (programul sursă), deoarece acesta cunoaşte cel mai bine 
programul sursă şi poate fi solicitat de inspectori să explice ce a 
intenţionat să facă atunci când aceştia consideră că ceva este greşit sau 
neclar. 

Membrii echipei de examinare vor primi programele sursă, 
specificaţiile de proiectare şi documentaţia asociată cu câteva zile înainte 
de desfăşurarea sesiunii de lucru. În timpul şedinţelor de lucru, 
examinatorii vor interpreta liniile de program, mai multe linii deodată, iar 
pe baza comentariilor şi întrebărilor formulate se vor descoperi 
eventualele greşeli. De asemenea, programele vor fi analizate pe baza 
listei de control a erorilor tipice. Rezultatele sesiunii de examinare vor fi 
consemnate într-o listă a problemelor identificate. Aceste probleme nu 
vor fi rezolvate în cadrul şedinţelor de examinare pentru a nu distratge 
atenţia membrilor echipei de la obiectivul principal, respectiv 
identificarea erorilor. Lista cu problemele identificate va fi înmânată 
programatorilor care au scris codul pentru rezolvarea lor. Dacă 
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problemele identificate au fost numeroase şi grave, este posibil ca după 
rezolvarea lor programele respective să fie supuse unei a doua sesiuni de 
examinare. 

Execuţia de probă, spre deosebire de examinări, presupune analiza 
programelor prin urmărirea efectului fiecărei instrucţiuni pe baza unor 
date de test. Datele de test alese sunt de cele mai multe ori simple, astfel 
încât să nu facă dificilă urmărirea programului. De fapt, datele de test vor 
servi mai mult drept punct de pornire a discuţiilor decât unei testări 
riguroase. Pe parcursul sesiunii de lucru, proiectantul poate fi solicitat să 
argumenteze şi să explice deciziile sale. 

Ambele tehnici de testare pot fi aplicate în cadrul tuturor fazelor de 
dezvoltare a sistemului informatic, şi nu doar în faza de implementare, cu 
condiţia existenţei unei documentaţii clare pe baza căreia să se poată 
realiza testarea. 

În afară de numărul mare de erori descoperite prin urmărirea 
atentă a programelor (după unele estimări între 60% şi 90%5), ambele 
tehnici prezintă şi alte avantaje: promovarea spiritului de echipă; membrii 
unei echipe pot învăţa unii de la alţii şi pot acumula cunoştinţe noi privind 
tehnicile şi stilurile de programare, erorile tipice care pot apare la 
scrierea programelor etc. 


5.2.6 Testarea bazată pe identificarea greşelilor 

După cum a fost prezentat la clasificarea tehnicilor de testare, acest 
tip de testare nu urmăreşte în mod direct validarea programelor, ci a 
însuşi setului de teste definit, pentru a determina capacitatea sa de 
identificare a erorilor. Aceste tehnici de testare se bazează pe estimările 
statistice. 

Una dintre cele mai simple tehnici de acest tip este tehnica 
„însămânţării” erorilor, prin care se încearcă estimarea numărului de 
erori dintr-un program pe baza numărului de erori introduse în program 
în mod intenţionat. După introducerea unor erori intenţionate în program, 
prin aplicarea setului de teste definit vor fi identificate atât erorile 
intenţionate cât şi altele noi. Numărul total de erori poate fi estimat pe 
baza numărului de erori din cele două categorii, astfel: 


Numărul erorilor noi identificate * Numărul erorilor intenţionate / Numărul 
erorilor intenţionate identificate 

Relativitatea estimării este generată de faptul că se porneşte de la 
premisa că erorile intenţionate şi cele reale au aceeaşi distribuţie 
statistică. De aceea, rezultatele obţinute prin aplicarea acestei tehnici 
trebuie interpretate astfel: dacă numărul erorilor intenţionate identificate 
este mare, iar cel al erorilor noi este mic atunci putem spune că avem 
rezultate pozitive. Contrariul nu este valabil. Mai mult, în general, dacă în 
urma testării sunt identificate multe erori noi, atunci nici într-un caz nu 
reprezintă un aspect pozitiv ci, dimpotrivă, pune în discuţie calitatea 
obiectului testat. 

O altă tehnică din această categorie o reprezintă tehnica 
modificărilor. Această tehnică presupune efectuarea unor modificări în 
programul de testat şi analiza efectelor asupra rezultatelor testării. 


5 Oprea, D., Op.cit., p.481 
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Să considerăm, de exemplu, un program P a cărui testare prin 
intermediul testelor T1 şi T2 produce rezultate corecte. P’ este o variantă 
a programului P în care s-a efectuat o singură modificare (de exemplu s-a 
schimbat un semn într-o expresie de calcul). Să presupunem că prin 
aplicarea celor două teste (T1 şi T2) asupra programului P’, testul T1 
produce aceleaşi rezultate în timp ce prin testul T2 se obţin rezultate 
diferite. In acest caz problema este la testul T1, deoarece rezultatele 
testării sunt aceleaşi chiar dacă s-a efectuat o modificare în program. De 
fapt, obiectivul urmărit prin aplicarea acestei tehnici vizează 
descoperirea testelor nerelevante din perspectiva identificării erorilor de 
program. 

Analiza modificărilor, ca tehnică de testare, presupune generarea 
unui număr mare de variante ale programului de testat, numiţi mutanti, 
care diferă în mică măsură de programul original. Exemple de operaţii de 
modificare a programului pentru obţinerea mutanţilor sunt: înlocuirea 
unei constante cu alta, înlocuirea unei variabile cu alta, înlocuirea unui 
operator aritmetic/logic cu alt operator aritmetic/logic, ştergerea unei 
instrucţiuni etc. 

După generarea lor, toţi mutanţii vor fi lansați în execuţie pe baza 
unui set de teste. Dacă setul de teste produce rezultate diferite pentru un 
mutant, atunci se spune că acel mutant este mort. Altfel, dacă rezultatele 
sunt aceleaşi pentru toate testele, atunci se spune că mutantul este (încă) 
viu. Evident că, dacă numărul mutanţilor vii este prea mare, atunci setul 
de teste respectiv nu este bun. Astfel, calitatea unui set de teste poate fi 
apreciată prin indicatorul gradul de acoperire a schimbărilor, calculat ca 
raport între numărul mutanţilor vii şi numărul mutanţilor morţi. În funcţie 
de valoarea acestui indicator se poate renunţa la seturile de date de test 
care nu dau rezultate satisfăcătoare. 


5.3 Strategia testării sistemelor informatice 

Testarea presupune un grup de activităţi care pot fi planificate din 
timp şi realizate în mod sistematic. Din acest motiv, trebuie definit un 
cadru de desfăşurare a etapei de testare ca parte a demersului dezvoltării 
sistemelor informatice. Acest cadru se concretizează în strategia testării. 

Strategia testării sistemelor informatice integrează diferitele 
metode de concepere a cazurilor de test într-o succesiune de paşi bine 
planificaţi astfel încât să fie asigurată dezvoltarea unui sistem informatic 
de calitate. De asemenea, strategia testării include detalii privind 
resursele de timp şi financiare necesare realizării testării. Prin urmare, 
strategia testării va include: planificarea testării, conceperea cazurilor de 
test care vor forma setul de teste, execuţia setului de teste, colectarea 
rezultatelor testării şi evaluarea acestor rezultate. 

Orice strategie de testare trebuie să aibă următoarele caracteristici 
generale: 

1. Testarea începe de jos, de la nivelul modulelor, şi se 
încheie prin validarea sistemului informatic ca un tot. O strategie 
de testare trebuie să garanteze atât verificarea corectitudinii 
implementării modulelor de program, cât şi validarea principalelor funcţii 
ale sistemului informatic, în conformitate cu cerinţele utilizatorilor. 
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În faza de proiectare, sistemul este descompus în mai multe module 
organizate ierarhic, ceea ce constituie de fapt arhitectura sistemului. În 
faza de testare va fi urmată aceeaşi arhitectură. Astfel, se va începe cu 
testarea modulelor, care presupune testarea fiecărui modul în parte. 
Apoi, testarea va viza modul de integrare a modulelor pentru obţinerea 
sistemului, conform arhitecturii definite în faza de proiectare. Această 
etapă este denumită testarea integrării. După testarea integrării, odată 
ce sistemul a fost refăcut prin integrarea modulelor, urmează testarea 
sistemului, moment în care programele şi alte elemente componente ale 
sistemului sunt testate ca un tot, în funcţie de cerinţele funcţionale şi 
restricţiile definite în faza de analiză, specificaţiile generale de 
proiectare. Se încheie cu testarea de acceptare, realizată sub 
supravegherea şi cu participarea directă a utilizatorilor. 

2. Diferitele tehnici de testare trebuie aplicate la anumite 
momente ale testării. De exemplu, la testarea modulelor se utilizează 
cu precădere tehnicile de tip „cutia albă”, prin care se va urmări execuţia 
fiecărei căi din fluxul logic de control al modulelor, testarea variabilelor 
de memorie şi a structurilor logice de control. În timpul testării integrării 
vor fi utilizate mai mult tehnicile de tip „cutia neagră” şi mai puţin cele de 
tip „cutia albă”. Testarea sistemului şi testarea de acceptare implică 
aproape în exclusivitate apelarea la tehnicile de tip „cutia neagră”, 
pentru a se verifica funcţionalitatea, comportamentul şi performanţele 
sistemului, precum şi dacă sistemul corespunde exigenţelor utilizatorilor. 

3. Testarea este realizată de către o echipă independentă, în 
cazul proiectelor mari sau de membrii echipei de dezvoltare a 
sistemului, în cazul proiectelor de mai mică amploare. Pentru orice 
proiect de dezvoltare a sistemelor informatice, faza de testare implică 
anumite conflicte de interese inerente. Pe de o parte, pare evident că cei 
mai potriviţi pentru a realiza testarea sunt proiectanţii şi programatorii, 
adică cei care cunosc cel mai bine sistemul. Pe de altă parte, aceştia vor 
încerca să demonstreze că programele nu conţin erori, iar prin testele 
proiectate vor demonstra că sistemul funcţionează conform cu cerinţele 
formulate. 

Din punct de vedere psihologic există două puncte de vedere: unul 
consideră dezvoltarea sistemului ca o activitate constructivă, în urma 
căreia sunt create specificaţiile de proiectare, programele, documentaţia 
etc., de care în mod evident membrii echipei de dezvoltare se simt 
mândri; celălalt punct de vedere consideră testarea ca o activitate 
destructivă, atât timp cât ea identifică erorile şi demonstrează că 
programele nu sunt tocmai aşa cum credeau cei care le-au realizat. De 
aceea, de multe ori se greşeşte atunci când se consideră că proiectanţii şi 
programatorii nu trebuie implicaţi în faza de testare sau că testerii vor fi 
implicaţi numai atunci când începe faza de testare. 

În general, proiectanţii şi programatorii sunt responsabili atât 
pentru testarea modulelor cât şi pentru testarea integrării modulelor, iar 
după ce aceste două etape s-au încheiat testarea va fi realizată de o 
echipă independentă. Rolul unei astfel de echipe constă în eliminarea 
conflictului de interese amintit anterior, ea fiind de fapt plătită pentru a 
găsi erori. Oricum, echipa de testare va colabora strâns cu echipa de 
proiectare şi programare care trebuie să rezolve eventualele erori. 
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5.3.1 Testarea modulelor 

Scopul principal urmărit prin testarea la nivelul modulelor constă în 
identificarea şi corectarea unui număr cât mai mare de erori înainte de 
integrarea modulelor în unităţi de program mai complexe, în care erorile 
sunt mult mai greu de depistat, localizat şi corectat. 

În acest moment al testării sunt implicate mai multe tehnici de 
testare, în funcţie de aspectele urmărite. De regulă, se începe cu testarea 
interfețelor modulului pentru a se asigura că intrările şi ieşirile în/din 
modul sunt corespunzătoare, înainte de a se efectua alte teste asupra 
modulului. Dacă interfețele modulului sunt necorespunzătoare, atunci 
toate celelalte teste sunt inutile. 

Urmează testarea structurilor de date locale, prin care se verifică 
integritatea datelor stocate temporar de-a lungul tuturor ramurilor de 
execuţie ale algoritmului transpus în modulul respectiv. Testarea 
interfeţelor şi a structurilor de date locale poate fi realizată prin 
intermediul tehnicii de testare bazată pe analiza fluxurilor de date. 

Cele mai importante teste dintre cele efectuate la nivelul modulelor 
sunt cele care vizează căile de execuţie ale programului. Prin testarea 
căilor de execuție ale programului se urmăreşte depistarea erorilor legate 
de calcule greşite, comparații greşite în expresiile logice, controlul logic 
al execuţiei necorespunzător etc. Foarte utile în acest scop sunt tehnica 
testării căilor de bază şi testarea structurilor de control repetitive. 

Testarea modulelor se încheie cu analiza valorilor limită. Deşi sunt 
puţine explicaţii, majoritatea erorilor apar la extremităţile domeniului de 
valori pentru datele de intrare şi nu în mijlocul acestui domeniu. De 
exemplu, apar erori la execuţie atunci când se invocă ultima iteraţie 
dintr-o structură repetitivă, se prelucrează ultimului element dintr-un 
tablou de date etc. Din acest motiv, se impune reluarea testelor privind 
structurile de date şi fluxul logic de control, însă vor fi utilizate alte cazuri 
de test prin care se va urmări exersarea valorilor limită ale domeniului. 

Analiza valorilor limită este considerată de mulţi specialişti o 
tehnică de testare. Aplicarea ei presupune: 

> Dacă printr-o condiţie se specifică un domeniu de valori curpins 
între un minim (a) şi un maxim (b), atunci trebuie concepute cazuri de 
test în care valorile să fie a, b, a+1, b+1, a-1 şi b-1; 

> Dacă domeniul unei condiţii va fi specificat printr-un număr de 
valori, vor fi generate cazuri de teste pentru situaţiile în care domeniul 
conţine numărul minim de valori, numărul minim + 1, numărul maxim de 
valori şi numărul maxim - 1; 

> Dacă pentru o structură de date locală a fost definită o restricţie 
(dimensiunea unui vector a fost declarată ca fiind 10), atunci se vor testa 
situaţiile când vectorul conţine un singur element, respectiv 10 elemente. 

Testarea modulelor mai are o particularitate. După cum se ştie, un 
modul nu este de sine-stătător, el fiind plasat undeva în structura 
ierarhică a programului de unde este apelat de modulele de pe nivelul 
ierarhic superior, după cum, la rândul său, poate apela unele module 
situate pe nivelul ierarhic inferior pentru a-şi putea realiza funcţia. Ori, în 
aceste condiţii, aplicarea tehnicilor de testare dinamică este de cele mai 
multe ori imposibilă. Pentru a se evita acest neajuns, pentru fiecare 


17 


modul testat se vor concepe două tipuri speciale de module: module ciot 
(stub) şi module directoare (drive). 

Un modul director este văzut ca un program principal al cărui rol 
constă în a simula condiţiile normale de exploatare a programului în care 
va fi executat modulul testat. Funcţiile lui privesc acceptarea datelor de 
test, transmiterea lor către modulul ce trebuie testat şi afişarea 
rezultatelor relevante ale testării. Un modul ciot are rolul de a înlocui un 
modul invocat de modulul testat, el fiind un subprogram care va avea 
aceeaşi interfaţă ca şi modulul pe care-l înlocuieşte, va realiza un minim 
de prelucrări, va semnala faptul că el a fost apelat după care va reda 
controlul modulului testat. 

La nivelurile inferioare, fiecare modul are nevoie de propriul modul 
director pentru a putea fi testat, ceea ce implică un consum mare de 
resurse pentru scrierea de cod suplimentar şi, în acelaşi timp, o sursă 
suplimentară de erori. Modulele director şi modulele ciot nu vor face 
parte din sistemul informatic, nu vor fi livrate beneficiarului, deci ele 
trebuie proiectate şi implementate suplimentar. În cazul în care pentru 
testarea unui modul sunt necesare astfel de module mai complexe, atunci 
se va amâna testarea modulului respectiv pentru pasul următor, respectiv 
testarea integrării, când de asemenea se apelează la astfel de module 
speciale, dar într-un număr mai redus. 

Testarea modulelor este simplificată cu atât mai mult cu cât 
coeziunea lor este mai mare. Dacă un modul este caracterizat de o 
coeziune funcţională, deci el a fost proiectat să realizeze o singură 
funcţie, atunci numărul testelor necesare este mai redus, iar erorile pot fi 
mai uşor descoperite. 


5.3.2 Testarea integrării 

Ajunşi în această etapă, unii (mai cârcotaşi) ar pune următoarea 
întrebare: de ce mai este necesară testarea integrării modulelor atât timp 
cât fiecare modul a fost testat individual şi se presupune că ele 
funcţionează ireproşabil? Răspunsul este uşor de intuit (dar şi uşor 
evaziv): pentru că pot apare alte erori. 

Această etapă a procesului de testare urmăreşte testarea grupurilor 
de module în vederea identificării erorilor ce nu au fost descoperite sau 
nu pot fi descoperite prin testarea la nivelul modulelor. Într-adevăr, 
anumite date se pot pierde prin transmiterea lor de la un modul la altul 
ca interfeţe, sau execuţia unui modul poate avea efecte negative asupra 
altui modul. De asemenea, integrarea subfuncţiilor realizate de diferite 
module poate să nu ducă la obţinerea funcţiei dorite sau pot apare unele 
probleme la utilizarea structurilor de date globale. Lista ar putea 
continua. 

Integrarea modulelor se poate face treptat, modul cu modul, sau 
deodată. Strategia integrării treptate presupune construirea şi testarea 
programului în paşi mici, astfel încât erorile să fie uşor de localizat şi 
corectat, interfețele să fie cât mai complet testate, iar întreaga activitate 
de testare a integrării modulelor să fie desfăşurată de o manieră 
sistematică. In opoziţie cu această strategie, integrarea deodată a 
modulelor presupune construirea programului prin integrarea modulelor 
componente urmată de testarea programului ca un tot. Această strategie 
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nu este recomandată deoarece face dificilă corectarea erorilor. În primul 
rând, datorită amplorii programului erorile sunt greu de localizat. În al 
doilea rând, tot procesul de testare va fi unul greoi deoarece după 
identificarea şi corectarea unei erori poate să apară alta, ceea ce face 
necesară reluarea testării până când nu mai apare altă eroare. 


5.3.2.1 Integrarea top-down 

Integrarea şi testarea modulelor începe cu modulul principal, după 
care se continuă prin parcurgerea în jos a structurii ierarhice a 
programului în una din următoarele două modalităţi posibile: integrarea 
orientată în adâncime sau integrarea orientată pe lăţime. 

Integrarea orientată în adâncime presupune integrarea tuturor 
modulelor componente pe câte o ramură importantă a structurii 
ierarhice. Alegerea ramurilor logice importante este oarecum arbitrară, 
ea depinzând de caracteristicile sistemului informatic. De exemplu, în 
cazul cel mai simplu, se pot alege trei ramuri importante, 
corespunzătoare ramurilor aferente, principale şi eferente din diagrama 
fluxurilor de date. 


Figura 5.6 Integrarea top-down 


De exemplu, pentru arhitectura din figura 5.6 se poate alege mai 
întâi ramura din stânga, caz în care vor fi integrate şi testate pe rând 
modulele M1, M2 şi M5, după care vor fi integrate modulele M10 şi M6. 
După finalizarea testării ramurii din stânga, se va trece la integrarea şi 
testarea în aceeaşi manieră a ramurilor centrală şi din dreapta. 

Integrarea orientată pe lăţime presupune integrarea mai întâi a 
modulelor situate pe nivelul ierarhic imediat inferior modulului principal 
şi se continuă în acest mod cu fiecare nivel ierarhic. Revenind la 
arhitectura din figura 5.6, vor fi integrate şi testate mai întâi M2, M3 şi 
M4, apoi M5 şi M6 ş.a.m.d. 

Aplicarea integrării top-down impune utilizarea modulelor ciot. Se 
începe prin testarea modulului principal, considerat ca un modul director, 
iar modulele subordonate direct vor fi înlocuite cu module ciot. Apoi, în 
funcţie de maniera de integrare (în adâncime sau pe lăţime), modulele 
ciot vor fi înlocuite pe rând cu modulele adevărate. După înlocuirea unui 
modul ciot se vor executa toate testele planificate şi numai apoi se va 
trece la înlocuirea următorului modul ciot. Se reia acest proces până la 
integrarea tuturor modulelor programului. 
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5.3.2.3 Integrarea bottom-up 

După cum îi spune şi numele, acest tip de integrare presupune 
construirea şi testarea treptată a programului începând cu modulele de 
pe ultimele niveluri ierarhice. În acest caz nu mai sunt necesare modulele 
ciot, deoarece în momentul testării unui modul toate modulele 
subordonate au fost deja integrate şi testate. In schimb, sunt necesare 
modulele director. 

Integrarea şi testarea bottom-up se desfăşoară după următorul 
scenariu: modulele situate pe ultimele niveluri ierarhice sunt grupate 
astfel încât fiecare grup de module să realizeze o subfuncţie a 
programului; apoi se creează câte un modul director pentru fiecare grup 
de module şi pe baza căruia se va testa fiecare grup în parte; după ce 
testarea fiecărui grup de module s-a încheiat, se elimină modulele 
director şi se regrupează modulele prin înglobarea modulelor situate pe 
nivelul imediat superior. Acest proces văd M1 lat până la construirea şi 
testarea întregului program. 


Figura 5.7 Strategia testării prin itegrarea bottom-up 


În figura 5.7, fiecare din cele trei grupuri de module este testat prin 
utilizarea modulelor director D1, D2 şi D3. Apoi, modulele director D1 şi 
D2 sunt eliminate, iar grupurile de module G1 şi G2 vor fi integrate şi vor 
interacţiona direct cu modul M2. După testarea noului grup de module, 
va fi eliminat şi D3 astfel încât grupul de module G3 va fi integrat şi va 
interacţiona direct cu modulul M3. In final, modulele M2 şi M3 vor fi 
integrate cu modulul M1 şi vor fi testate. 

Pe măsură ce se înaintează în ierarhie, numărul modulelor director 
se micşorează. Dacă s-ar aplica integrarea top-down pentru primele două 
niveluri ierarhice din structura programului, atunci numărul modulelor 
director necesare s-ar reduce substanţial, iar integrarea grupurilor de 
module ar fi mult simplificată. De aceea, în practică se îmbină cele două 
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tipuri de testări, respectiv integrarea top-down şi bottom-up, fiecare 
prezentând avantaje şi dezavantaje specifice. 

Spre pildă, integrarea top-down permite testarea principalelor 
puncte decizionale încă din primele momente ale testării, dacă 
arhitectura programului a fost proiectată conform cerinţei înglobării 
principalelor decizii din logica programului în modulele situate pe 
nivelurile superioare ale structurii programului. De asemenea, prin 
integrarea orientată în adâncime programul poate fi ansamblat şi testat 
pe funcţii ale sale, ceea ce facilitează ulterior testarea sistemului şi 
testarea de acceptare. 


5.3.3 Testarea întregului sistem 
După testarea integrării, urmează testarea întregului sistem. Deşi 
testarea sistemului este similară cu testarea integrării, ea diferă totuşi 
prin orientarea testelor spre acele caracteristici nespecifice 
componentelor programului cum ar fi: performanțele sistemului, 
securitatea, refacerea în cazul apariţiei unor căderi ale sistemului etc. De 
asemenea, testarea sistemului diferă de testările anterioare prin luarea în 
considerare şi a celorlalte componente ale sistemului, în afară de 
programe. Aceste teste vor verifica dacă elementele componente ale 
sistemului - hardware, software, oameni şi date - sunt integrate 
corespunzător şi realizează funcțiile prevăzute. 
Testele concepute în această fază pot fi împărţite în patru categorii, 
în funcţie de scopul urmărit: 
> Testarea refacerii urmăreşte să forţeze căderea sistemului din 
diferite cauze şi să verifice dacă refacerea este realizată 
corespunzător. Din acest punct de vedere, unele sisteme 
informatice sunt concepute ca fiind tolerante la erori, adică 
apariţia unor erori nu determină întreruperea funcţionării 
sistemului, iar altele presupun întreruperea temporară a 
funcţionării sistemului şi rezolvarea problemelor într-o 
anumită perioadă de timp. Dacă refacerea este realizată 
automat de către sistemul însuşi, vor fi verificate 
reiniţializarea sistemului, refacerea datelor şi alte aspecte ale 
sistemului. Dacă refacerea implică intervenţia beneficiarului, 
va fi evaluată perioada de timp necesară pentru repunerea 
sistemului în funcţiune, apreciindu-se dacă este în limitele 
acceptate. 
> Testarea securităţii urmăreşte să verifice dacă mecanismele 
de protecţie ale sistemului funcţionează corespunzător 
împotriva încercărilor de atac asupra sistemului sau a 
accesării neautorizate. În timpul acestei testări, testerul va 
juca rolul celui care doreşte să atace sistemul, încercând 
diverse posibilităţi de spargere a acestuia. Desigur că, având 
la dispoziţie timpul şi resursele necesare, sistemul va fi 
penetrat dacă testele sunt bine realizate. Rolul proiectanţilor 
sistemului este de a concepe sistemul astfel încât costurile 
accesării neautorizate a sistemului să fie mai mari decât 
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valoarea informaţiilor care ar putea fi astfel obţinute sau 
valoarea pagubelor care ar putea fi produse. 

> Testarea solicitării sistemului presupune confruntarea 
sistemului cu situaţii anormale, testările anterioare verificând 
modul de funcţionare a programelor în condiţii normale de 
lucru. Prin testele concepute, execuţia programelor va solicita 
resurse în cantităţi, volume sau frecvenţe anormale. De 
exemplu, pot fi concepute teste pentru situaţiile în care 
volumul şi rata datelor de intrare creşte de un anumit număr 
de ori faţă de situaţiile normale, teste în care timpul de 
căutare şi citire a datelor de pe disc este foarte mare, teste 
care să genereze 10 întreruperi pe scundă, chiar dacă media 
este de doua întreruperi pe secundă etc. 

> Testarea performanțelor sistemului verifică performanţele 
obţinute în momentul execuţiei programelor în contextul 
integrării tuturor componentelor sistemului. Această testare 
este adesea combinată cu testarea solicitării sistemului şi ia 
în considerare, în general, performanţele tehnice ale 

: hardware-ului şi software-ului. 

În principiu, testarea sistemului va include toate activităţile 
specifice testării de acceptare, însă ea va fi realizată fără implicarea 
utilizatorilor. Astfel, ea oferă ocazia ultimelor verificări şi modificări 
înainte de prezentarea sistemului în faţa beneficiarului. 

5.3.4 Testarea de acceptare 

Testarea de acceptare reprezintă ultima ocazie de verificare a 
sistemului informatic, iar dacă aceste ultime teste sunt trecute cu bine, 
atunci sistemul informatic va fi dat în exploatare. Spre deosebire de 
testele anterioare, testarea de acceptare trebuie să se desfăşoare într-un 
mediu similar celui în care va fi pus în funcţiune şi de către persoanele 
care îl vor utiliza. Ea este realizată din perspectiva utilizatorului, ceea ce 
înseamnă că prin testele concepute vor fi exersate funcţiile aplicaţiei 
orientate spre utilizator. 

Testarea de acceptare trebuie planificată încă din primele faze ale 
dezvoltării sistemului, începând cu analiza. Dacă planificarea testării de 
acceptare începe din faza de analiză, atunci în paralel cu definirea 
cerinţelor sistemului se va stabili şi modul în care fiecare cerinţă poate fi 
testată cât mai bine. Mai mult, dacă o anumită cerinţă este dificil de 
testat şi de întreţinut, atunci utilizatorului i se poate oferi unele explicaţii 
care să-l determine să renunţe la acea cerinţă. 

Planul testării de acceptare trebuie să constituie în fapt strategia de 
testare a principalelor componente sau funcţii ale sistemului care să 
garanteze exploatarea ulterioară a sistemului în condiţiile cele mai bune. 
Analiştii trebuie să colaboreze cât mai strâns cu utilizatorii în definirea 
obiectivelor şi conţinutului planului testării atât timp cât ei sunt cei care 
vor decide acceptarea sau respingerea sistemului. Prin urmare, analiştii 
trebuie să ia împreună cu utilizatorii decizia asupra testelor minime care 
trebuie realizate. 

Cel mai indicat ar fi ca, pe baza cerinţelor formulate în faza de 
analiză şi a descompunerii funcţionale realizată cu ajutorul diagramelor 
fluxurilor de date sau a altor instrumente, analistul să dezvolte un plan 
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general de testare care să fie îmbunătăţit în urma discuţiilor cu 
utilizatorii. Aceştia pot adăuga eventualele teste pe care le consideră 
relevante din punctul lor de vedere. Planul trebuie transpus într-un 
format care să fie uşor de înţeles şi urmărit de utilizatori, astfel încât 
aceştia să participe activ la planificare. 

Testarea de acceptare presupune, de regulă, două etape: testarea 
alfa şi testarea beta. Testarea alfa este realizată de client la sediul 
producătorului, sub supravegherea specialiştilor din echipa de dezvoltare 
a sistemului, şi sunt utilizate date nereale dar reprezentative. În schimb, 
testarea beta se desfăşoară la sediul clientului, fără ca utilizatorii să mai 
fie supravegheați de membrii echipei de dezvoltare a sistemului, 
utilizându-se date reale. De fapt, testarea beta reprezintă un fel de 
repetiţie generală înaintea exploatării propriu-zise a sistemului. 

Un test de acceptare poate avea ca rezultat trei posibilităţi: reuşit, 
rezervat sau eşec. Pentru fiecare test se va specifica rezultatul minim 
acceptat, iar dacă pentru toate testele s-au obţinut rezultatele minime, 
atunci sistemul poate fi acceptat. 
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